Ransomware‑resilient backups: 3‑2‑1, testing, and pitfalls to avoid
Here’s a tight, CERT‑style, vendor‑aligned checklist you can drop straight into your content or products.

1. Apply the 3‑2‑1 (modernized) backup rule
3 copies of your data:

1 production copy

2 backup copies

2 different types of media:

Example: local backup appliance/NAS and cloud backup

1 off‑site copy:

Physically separate or in a different cloud region

Bonus (3‑2‑1‑1‑0 pattern):

+1 immutable copy (write‑once, read‑many)

0 errors in restore tests

2. Make backups hard for ransomware to reach
Separate credentials:

Backup admin accounts must be different from domain/Windows admins

No shared “god” accounts:

Avoid using the same account for servers, backups, and storage

Network separation:

Put backup storage on a separate VLAN/network where possible

Use immutability / object lock:

Enable write‑once retention on backup repositories or cloud buckets

Limit delete rights:

Require MFA and/or approval for deleting backup sets or changing retention

3. Design backups for recovery, not just storage
Prioritize critical systems:

Accounting, CRM, file shares, email, identity (AD/Entra), key SaaS configs

Define RPO/RTO:

RPO: How much data (time) you can afford to lose

RTO: How long you can afford to be down

Use application‑aware backups:

Databases, VMs, email, and directory services where supported

Include configuration backups:

Firewalls, switches, SaaS tenant configs, backup server config itself

4. Test restores regularly (not just “backup success”)
Schedule restore tests:

At least quarterly; monthly is better

Test multiple levels:

File‑level restore (single file/folder)

System/VM restore (boot and login)

Scenario test: “Ransomware hit this server—can we rebuild it?”

Verify integrity:

Open restored files, log into restored systems, confirm apps actually run

Document results:

Time to restore vs. RTO

Any failures, fixes, and follow‑up actions

5. Avoid these common backup pitfalls
Only one backup copy on the same device/NAS as production

Backups permanently online with full read/write/delete access

Relying on sync tools (OneDrive/Drive/Dropbox) as “backups”

Never testing restores until an actual incident

No off‑site or immutable copy

Using shared admin accounts for everything

Letting backup storage fill up until jobs silently fail

6. Ransomware‑specific hardening moves
Enable MFA everywhere:

Backup console, storage accounts, cloud portals

Log and monitor backup activity:

Alerts for mass deletions, policy changes, failed jobs

Protect backup server itself:

Patch regularly, restrict RDP/SSH, limit who can log in

Document an incident playbook:

Who to call, what to isolate, which backups to restore from, in what order

You follow this, and your backups stop being “nice to have” and start being your last, best line of defense against ransomware.

…and that’s the JUST of it.